Smart cards typically contain both non-volatile memory and volatile memory.
“Non-volatile” memory is memory that can store data without requiring external power. Non-volatile memory can be programmable (examples are EEPROM memory, flash memory, etc.) or non-programmable (an example is ROM memory, whose content is defined once and for all at manufacture). Programmable non-volatile memories are often used to store data or applications that can vary from one card to another, for example a file system containing different directories and subdirectories, files with data specific to the cardholder (name, contact information, etc.), JavaCard applets, etc. Smart cards typically have a capacity of about 8 KB to 256 KB of programmable non-volatile memory (usually EEPROM). Non-programmable non-volatile memory is often used to store an operating system, and (more generally) data that is unlikely to change from one card to another. Smart cards typically have a capacity of about 64 KB to 512 KB of ROM. Of course, other amounts of RAM, EEPROM or ROM also exist. Some smart cards use flash memory instead of ROM and EEPROM together.
“Volatile” memory (such as RAM memory) is memory that loses its content when the external power supplied to it is interrupted. Volatile memory is typically much faster than non-volatile memory, especially for write operations. For example, a write to EEPROM or flash memory is generally much slower than a RAM write. Volatile memory is used for example to store temporary data (state variables, calculation results, etc.) during the execution of software. Smart cards typically include RAM memory, which is usually between 2 KB and 8 KB. Much of this RAM is generally occupied by variables (particularly for the card's operating system) and by different applications. Part of the RAM is generally occupied by a buffer, which is typically a few hundred bytes in size and is dedicated to receiving commands.
A smart card generally does not allow outside entities to write to any of its memory by absolute addressing. Instead, smart cards typically offer an interface (such as an ISO 7816-4 interface) through which an outside entity can send commands to the card (including read or write commands). The commands are received in the buffer. It is the card itself which is responsible for executing the commands received, and it can choose to process them or reject them, prohibit certain accesses, subject some accesses to authentication, etc. According to the T=0 protocol of the ISO 7816-4 standard, which is the most common protocol, the commands contain five bytes (class byte, instruction byte, and three bytes of parameters P1, P2 and P3), optionally followed by data (for example data to be written to the card). The length of any such data is usually specified by byte P3, and therefore no more than 255 bytes (plus the previous 5 bytes) are sent at once. This, however, requires a buffer of at least 260 bytes. Other variants and other protocols also exist (such as the T=1 protocol, which theoretically is able to send and receive up to 64 KB of data in a command).
Given the relatively small size of the buffer, and the limitations of the T=0 protocol, it is generally not possible to send very long commands to the card. If more than 255 bytes is to be written to a file on the card (T=0), the data is usually divided into smaller subsets (for example blocks of 255 bytes), and as many write commands as there are blocks are sent.
For example, the UPDATE BINARY command (instruction 0xD6 of the ISO 7816-4 standard) can be used, which allows writing to a so called “transparent” file. This is a file of type EF (Elementary File), to which one can write by specifying the target (between 0x0000, for the beginning of the file, and the address corresponding to the size of the file minus at least one byte, if you want to modify the last byte of the file). However, this requires that the sending entity calculate not only the data subsets (blocks of 255 bytes), but also the address where each block in the target file is to be written, which is impractical.
It is also known to use an UPDATE RECORD command (instruction 0xDC of the ISO 7816-4 standard), which allows creating an EF file of records with each record identified by an index. It is possible for each record to have a different size (depending on the card). However, this requires calculating record indexes, which is impractical. In addition, it is sometimes necessary to write blocks of one size (for example blocks of 11 bytes), but to read blocks of another size (for example blocks of 13 bytes); in this case the structure of a file of records is highly impractical because the data to be read straddle multiple records and record portions.
It is also known to use a PUT DATA command (instruction 0xDA of the ISO 7816-4 standard). The standard specifies that, depending on the object selected (which the PUT DATA command is to write to), it is possible to execute a “writing once” operation or an “updating” operation or an “appending” operation. However, the procedure of the “appending” operation is not specified in the standard.